Search Results

Gasoline Controlled Auto Ignition offers a high CO2 emission reduction potential, which is comparable to state-of-the-art, lean stratified operated gasoline engines. Contrary to the latter, GCAI low temperature combustion avoids NOX emissions, thereby trying to avoid extensive exhaust aftertreatment. The challenges remain in a restricted operation range due to combustion instabilities and a high sensitivity towards changing boundary conditions like ambient temperature, intake pressure or fuel properties. Once combustion shows instability, cyclic fluctuations are observed. These appear to have near-chaotic behavior but are characterized by a superposition of clearly deterministic and stochastic effects. Previous works show that the fluctuations can be predicted precisely when taking cycle-tocycle correlations into account. This work extends current approaches by focusing on additional dependencies within one single combustion cycle.

This paper describes challenges and possible solution of hybrid electrical vehicles test systems with a special focus on hardware-in-the-loop (HIL) test bench. The degree of novelty of this work can be seen in the fact that development and test of ECU for hybrid electrical powertrains can move more and more from mechanical test benches with real automotive components to HIL test systems. The challenging task in terms of electrical interface between an electric motor ECU and an HIL system and necessary real-time capable simulation models for electric machines have been investigated and partly solved. Even cell balancing strategies performed by battery management systems (BMU) can be developed and tested using HIL technology with battery simulation models and a precise cell voltage simulation on electrical level.

Automotive technology is rapidly changing with electrification of vehicles, driver assistance systems, advanced safety systems etc. This advancement in technology is making the task of validation and verification of embedded software complex and challenging. In addition to the component testing, integration testing imposes even tougher requirements for software testing. To meet these challenges dSPACE is continuously evolving the Hardware-In-the-Loop (HIL) technology to provide a systematic way to manage this task. The paper presents developments in the HIL hardware technology with latest quad-core processors, FPGA based I/O technology and communication bus systems such as Flexray. Also presented are developments of the software components such as advanced user interfaces, GPS information integration, real-time testing and simulation models. This paper provides a real-world example of implication of integration testing on HIL environment for Chassis Controls.

Hardware-in-the-loop (HIL) simulation is a real-time testing process that has been proven indispensable for the modern vehicle dynamics, powertrain, chassis and body systems electronic controls development. The high quality standards and robustness of the control algorithms can only be met by means of detailed vehicle plant simulation models. In the last few years, several efforts have been made to develop detailed plant models. Several tools for the vehicle modeling are available in the market and each tool has different and distinct advantages. This paper addresses ways that dSPACE Automotive Simulation Models (ASM) can support the model-based development processes. Additional modern software tools that were used in connection with the ASM are LMS AMESim and Mathworks SimDriveline (of Simscape). ASM is an open Matlab/Simulink model environment used for offline PC based simulation and online real-time platform HIL testing.

Model-based development is the established way of developing embedded control algorithms, especially for safety-critical applications. The aim is to improve development efficiency and safety by developing the software at a high abstraction level (the model) and by generating the implementation (the C code) automatically from the model. Although model-based development focuses on the models themselves, downstream artifacts such as source code or executable object code have to be considered in the verification stage. Safety standards such as ISO 26262 require upper bounds to be determined for the required storage space or the execution time of real-time tasks, and the absence of run-time errors to be demonstrated. Static analysis tools are available which work at the code level and can prove the absence of such errors. However, the connection to the model level has to be explicitly established.

The essential task of a battery management system (BMS) is to consistently operate the high-voltage battery in an optimum range. Due to the safety-critical nature of its components, prior testing of a BMS is absolutely necessary. Hardware-in-the-loop (HIL) simulation is a cost-effective and efficient tool for this. Testing the BMS on a HIL test bench requires an electronics unit to simulate the cell voltages and a scalable real-time battery model. This paper describes a HIL system that enables comprehensive testing of BMS components. Hardware and software solutions are proposed for the high requirements of these tests. The individual components are combined to make a modular system, and safety-critical aspects are examined. The paper shows that the system as developed fulfills all the requirements derived from the different test scenarios for BMS systems.

Hardware-in-the-loop (HIL) testing is an indispensable tool in the software development process for electronic control units (ECUs) and Logical Replaceable Units (LRUs) and is an integral part of the software validation process for many organizations. HIL simulation is regarded as the tried-and-tested method for function, component, integration and network tests for the entire system. Using the Model based design approach has further enabled improved and faster HIL implementations in recent years. This paper describes the changing requirements for HIL simulation, and how they need to be addressed by HIL technology. It also addresses the challenges faced while setting up a successful HIL system: namely the division of tasks, the total cost of ownership, budget constraints and tough competition and the adaptability of a HIL simulator to new demands. These requirements are discussed using a dSPACE HIL system architecture that was designed from the ground-up to address these needs.

Embedded software in the car is becoming increasingly complex due to the growing number of software-based controller functions and the increasing complexity of the software itself. Model-based development with Simulink combined with TargetLink for automatic code generation helps significantly to improve the quality of the embedded software. The development of large-scale Simulink models in distributed teams is a challenging task, especially when developing safety-critical software that must fulfill requirements stated in the ISO 26262 [1] safety standard. In practice, many questions on how to avoid the pitfalls of distributed model-based development remain open, such as how to define an appropriate model architecture, handle model complexity, and achieve compliance with ISO 26262. The intent of this paper is threefold. Firstly, we summarize those requirements of ISO 26262 that are relevant for developing complex software in a distributed environment.

Hardware-in-the-Loop Simulation is a technology where the actual vehicles, engines or other components are replaced by a real-time simulation in a simulation computer, based on a mathematical model. That simulation reads ECU (Electronic Control Unit) output signals which would normally go to actuators. On the other hand the simulation must output the sensor signals which make the ECU ‘think’ it controls a real system. Generating these signals can be very difficult. Signals may be complex, depend on on-line computed variables, and be required to be output at high timing resolution. This paper describes the problems and presents a solution which employs high-performance Digital Signal Processors (DSP) to generate such signals on-line by Direct-Digital-Synthesis (DDS).

The technological development in the field of automotive electronics is proceeding at almost break-neck speed. The functions being developed and integrated into cars are growing in complexity and volume. With the increasing number and variety of sensors and actuators, electronics have to handle a greater amount of data, and the acquisition and generation of I/O signals is also growing in complexity, for example, in engine management applications. Moreover, intelligent and complex algorithms need to be processed in a minimum of time. This all intensifies the need for Rapid Control Prototyping (RCP), a proven method of decisively speeding up the model-based software development process of automotive electronic control units (ECUs) [1],[2]. All these demanding tasks, including connecting sensors and actuators to the RCP system, need to be performed within a standard prototyping environment.

Hardware-in-the-loop (HIL) test benches are indispensable for the development of modern vehicle dynamics controllers (VDCs). They can be regarded as a standard methodology today, because of the extremely safety-critical nature of the multi-sensor and multi-actuator systems used in vehicle dynamics control. The required high quality standards can only be ensured by systematic testing within a virtual HIL environment before going into a real car. This paper aims to provide a condensed technical over-view of state-of-the-art HIL test systems for VDCs, which are currently widely used in passenger cars, in the form of ABS and TCS, as well as ESP, or integrated chassis control, which is just coming onto the market. First, a short introduction to the basic functionality of these types of ECUs is given, and the reasons why HIL testing is necessary and especially useful for VDCs are discussed.

The number of electrical and electronic components in modern vehicles is constantly growing. Increasingly, functionalities are being distributed across several electronic control units (ECUs). While suppliers themselves are responsible for ensuring that individual ECUs function properly, only the OEM can test distributed functions. Moreover, with the volume of testing steadily growing, automated sequences are absolutely essential. To test electronic networks in the vehicle, Ford Europe is using platform-based hardware-in-the-loop simulation with integrated failure insertion. The company is setting up a uniform, project-independent procedure, from standardized test definition to automated test sequences on a virtual vehicle, right through to structured evaluation.

Not only is the number of electronic control units (ECUs) in modern vehicles constantly increasing, the software of the ECUs is also becoming more complex. Both make testing a central task within the development of automotive electronics. Testing ECUs in real vehicles is time-consuming and costly, and comes very late in the automotive development process. It is therefore increasingly being replaced by laboratory tests using hardware-in-the-loop (HIL) simulation. While new software functions are still being developed or optimized, other functions are already undergoing certain tests, mostly on module level but also on system and integration level. To achieve the highest quality, testing must be done as early as possible within the development process. This paper describes the various test phases during the development of automotive electronics (from single function testing to network testing of all the ECUs of a vehicle).

The development of perception functions for tomorrow’s automated vehicles is driven by enormous amounts of data: often exceeding a gigabyte per second and reaching into the terabytes per hour. Data is typically gathered by a fleet of dozens of mule vehicles which multiply the data generated into the hundreds of petabytes per year. Traditional methods for fueling data-driven development would record every bit of every second of a data logging drive on solid-state drives located on a PC in the vehicle. Recorded data must then be exported from these drives using an upload station which pushes to the data lake after arriving back at the garage. This paper considers different techniques for curating logged data.

Increasing productivity along the development and verification process of safety-related projects is an important aspect in today’s technological developments, which need to be ever more efficient. The increase of productivity can be achieved by improving the usability of software tools and decreasing the effort of qualifying the software tool for a safety-related project. For safety-critical systems, the output of software tools has to be verified in order to ensure the tools’ suitability for safety-relevant applications. Verification is particularly important for test automation tools that are used to run hardware-in-the-loop (HIL) tests of safety-related software automatically 24/7. This qualification of software tools requires advanced knowledge and effort. This problem can be solved if a tool is suitable for developing safety-related software. This paper explains how this can be achieved for a COTS test automation tool.

This paper describes a new production code generator that meets both the requirements of code developers for efficient and reliable production code, as well as the desire of system engineers to establish a control design process based on simulation models that double as executable specifications for the ECU software. The production code generator supports automatic scaling, generates optimized fixed-point C code for microcontrollers like the Motorola 683xx, Siemens C16x, and Hitachi SH-2, and produces ASAP2 [1] calibration information. Benchmark results show that the autogenerated code can match or even exceed the efficiency of typical handwritten production code. Code quality is assured by design and by systematic, automatic, and extremely comprehensive test procedures.

This paper presents a demonstrator developed in the European CleanSky2 project MISSION (Modelling and Simulation Tools for Systems Integration on Aircraft). Its scope is the development towards a seamless integrated, interconnected toolchain enabling more efficient processes with less rework time in todays, highly collaborative aerospace domain design applications. The demonstration described here, consists of an open, modular and multitool platform implementation, using specific techniques to achieve fully traceable (early stage) requirements verification by virtual testing. The most promising approach is a model based integration along the whole process from requirements definition to the verified, integrated (and certified) system. Extending previous publications in this series, the paper introduces the motivation and briefly describes the technical background and a potential implementation of a workflow suitable for that target.

To make the development of complex aircraft systems manageable and economical, tests must be performed as early as possible in the development process. The test goals are already set in advance before the first hardware for the ECUs exists, to be able to make statements about the system functions or possible malfunctions. This paper describes the requirements on and solutions for test systems for ECUs that arise from these goals. It especially focuses on how a seamless workflow and consistent use of test systems and necessary software tools can be achieved, from the virtual test of ECUs, which exist only as models, up to the test of real hardware. This will be shown in connection with a scalable, fully software-configurable hardware-in-the-loop (HIL) technology. The paper also covers the seamless use of software tools that are required for HIL testing throughout the different test phases, enabling the reuse of work products throughout the test phases.

Hardware-in-the-loop (HIL) testing is indispensable in the software development process for control units and has been an integral part of the software development process for years. Large HIL systems for integration tests are used to test the correct behavior of distributed functions and the communication between the control units. The vast development programs that are involved require building duplicates of such test systems or parts of them, due to the fact that the tasks are distributed between different companies or different departments within a company. However, there is an alternative to duplicating a test system. Instead of using a cloned system, coupling HIL systems over large distances is an alternate approach. This paper presents what requirements this coupling must fulfill and and describes a path-breaking method to fulfill them. In addition, results of an implementation are shown.

Hardware-in-the-loop (HIL) simulation is now a standard component in the vehicle development process as a method for testing electronic control unit (ECU) software. HIL simulation is used for all aspects of development, naturally including safety-relevant functions and systems. This applies to all test tasks (from function testing to release tests, testing a single ECU or an ECU network, and so on) and also to different vehicle domains: The drivetrain, vehicle dynamics, driver assistance systems, interior/comfort systems and infotainment are all tested by HIL simulation. At the same time, modern vehicles feature more and more safety-related systems such as Adaptive Cruise Control, Electronic Stability Program, Power Assisted Steering, and Integrated Chassis Management.